Opravdový expert
|
5.5.20089:45
Co to zas bylo za zvíře, co spáchalo tenhle paskvil?! Pipelining že je odpověď na nedostatečnou rychlost šíření světla? Sakra, když už tomu autor vůbec nerozumí, tak ať to někde všecko prostě opíše, proč to musí ještě sežvýkávat svým rozoumkem? Nepsal tenhle člověk před časem ty zrůdnosti o grafice ve hrách, kde si vymýšlel nekonečné odrazy fotonů?
Odpovědět0 0
hondasek
|
19.5.20058:21
Elektrony se pohybuji v řádech 10 na 5tou m/s pri pokojové teplotě
Odpovědět0 0
PedroCZ
|
31.8.20047:00
Zdravim,
Chtěl jsem se zeptat zda-li internetový magazín světhardware spolupracuje s tištěným magazínem CHIP od Vogel publishing. Ptáme se, jelikož jsem předplatitel CHIPu a prvidelný čtenář světahardware a v srpnovém číslu CHIPU jsem našel stejný článek (ne doslovně) se stejnými obrázky ... Navíc jsem v také našel v srpnovém číslu CHIPu recenzi na stejnou sestavu lynx, kterou recenzoval p. Igor Viduna. Ptám se proto, jestli má cenu přeplácet CHIP, když to samé si můžu zadarmo přečíst na internetu :-)
Odpovědět0 0
Odstavec o pipeline neni spravne. Pipeline nevznikla kvuli konecne rychlosti signalu (ackoliv bych veril, ze dnes to CPU potrebuji take). Duvodem vzniku je hlavne zvyseni vykonu CPU. Vykonavani intrukce se totiz deje v nekolika krocich, napr. FETCH, DECODE, EXECUTE, STORE, v pripade neRISCovych procesoru dokonce jeste kazda z techto operaci (hlavne EXECUTE) muze obsahovat dalsi kroky. Kazdy krok odpovida jednomu taktu procesoru, potom napr. vyse uvedena intrukce by trvala 4 hodinove cykly. Vtip je v tom, ze pokud je intrukce treba ve stavu DECODE, pak cast CPU odpovedna za FETCH nedela nic. Proto pipeline rozkouskuje vykonavani instrukce a procesor zpracovava nekolik instrukci najednou v ruznych fazich rozpracovani. V idealnim pripade, tedy pokud jsou na sobe intrukce nezavisle, trva ve vysledku vykonani instrukce 1 cyklus. Krome pocatecni faze, kdy je potreba pipeline naplnit, je tedy narust vykonu ctyrnasobny, aniz by se jakkoliv zvysovala frekvence!!! Cim vic kroku ma zpracovani instrukce a tudiz moznych stupnu pipeline, tim je narust vyssi. Dokonce i v nejhorsim pripade, kdy jsou intrukce na sobe zavisle, nebude vykon nizsi nez v CPU bez pipeline.
Odpovědět0 0
Nechci se Vás dotknout, ale myslím si, že jste hlavní myšlenku pipeline nepochopil. Ona je totiž o tom, že se vykonávání rozdělí do více stupňů - již zmíněné fetch, decode, execute, write atd. Do těchto stupňů se rozdělí, protože rychlost signálů je příliš malá na to, aby se vše stihlo najednou. To, že je umožněno vykonávat v každé části jednu instrukci ve stejném taktu, je jen nutný důsledek designu - jinak by totiž výkon silně poklesl (ve Vašem příkladu 4x).
Odpovědět0 0
kqt
|
23.8.20049:24
Pane Orle, podle mě jste myšlenku pipeline nepochopil vy. Dost mě to děsí, protože většina čtenářů spoléhá na určitou úroveň publikovaných článků. Pokud se rozhodnete psát článek na určité téma, měl byste si prostudovat dostupnou literaturu. O této tématice obšírně informuje kniha 80-214-1458-8 Dvořák - Architektura procesorů .
Odpovědět0 0
ali
|
25.8.20049:53
Presne jak pise kqt - pipeline zpracovani resi hlavne problem nevyuzitych zdroju. 1. krokem je, ze zpracovani instrukce rozdelite do fazi (typicky fetch, decode, execute, memory, writeback) - diky tomu dosahnete jisteho zefektivneni, protoze ne vsechny instrukce potrebuji vsechny faze (napr. LOAD vs ARITM.) - mluvime o RISC. 2. krok pak je logickym rozsirenim zminene architektury - v kazdem taktu vyuzivame jen 1/pocet_fazi zdroju - proc tedy nezamestnat v kazdem taktu vsechny zdroje? To je klicova uvaha vedouci k aplikaci pipeline, nikoliv rychlost pohybu elmg. pole polovodicem.
Odpovědět0 0
Obávám se, že to není celá pravda, protože pak by delší pipeline vůbec neznamenala možnost vyšších frekvencí.
Odpovědět0 0
Jaj
|
27.8.20046:52
Orel si kokot nebo co ? zkus si o tom nejdriv neco precist v odborne literature, pak svoje zazitky konzultuj s nekym kdo ty procaky vyvyji (ne s nejakou uklizeckou ve FAB) a pak kydej na netu !!!
Odpovědět0 0
Ale no tak, klid :).
Nahodou, ikdyz si stojim za tim, co jsem o pipeline napsal, tak jinak si myslim, ze clanek je napsany dobre a urcite jsem se z nej dozvedel neco noveho.
Odpovědět0 0
Kua
|
21.2.20062:47
Tak se kua dohodněte kde je pravda, pak jsem z toho jelen a celej článek (kterej je super) vyzní naprd.
Odpovědět0 0
Ja jaj
|
31.8.200416:42
Hele sasku, zkus taky jednou pouzit svuj E-mail.
Odpovědět0 0
lmao
|
28.10.200513:44
vyvíjet :P šašku
Odpovědět0 0
luzr
|
5.5.20089:57
Pan "eagle" ma pravdu, pletete si pojmy. To co popisujete je rekneme OOOE - out of order execution (i kdyz tezko rict, popisujete to nepresne).
Pipilene je skutecne proto, ze rozdelenim do vic kroku se da zvysit frekvence.
Ostatne, nic neni zadarmo. Pokud bychom se ridili logikou zde uvedenou, znamenalo by to ze cim delsi pipeline, tim lepe, ze? Coz, jak znamo z historie, neplati (duvodem je ze pipeline je potreba zastavit a vysledky zahodit pokud se nespravne odhadne podminka u skoku).
Ve skutecnosti, cim kratsi pipeline, tim vyssi vykon na stejne frekvenci. Delsi pipeline, vykon na takt klesa ale mozna frekvence stoupa protoze hloubka logiky (tedy treba pocet tranzistoru kterymi musi ty elektrony projit a delka "dratu") klesa.
Samozrejme, pipeline je jenom takovy uplny zaklad ktery se objevil na sameme usvitu pocitacovych dejin. Moderni CPU pouziva dalsi, mnohem silenejsi optimalizace (jejichz kralem je prave OOOE), zrejme vas to zmatlo :)
Odpovědět0 0
Tom K
|
16.8.200416:54
Dik za clanek. Je zjevne, ze evolucni vyvoj CPU (Moore a pod.) miri ke svym limitum a musi prijit reolucni zmena. Muzete mi nkdo vysvetlit, proc se dosud neuplatnily CPU s masivne paralelni architekturou? Zatim se objevily pouze naznaky paralelismu (MMX, SSE, Intelovsky marketingem nafoyukly hyperthreading). Vzdyt dnesni "killer applications" (3D hry, (de)kodovani videa, rozpoznavani reci a obrazu) jsou pro paraleni zpracovani vhodne, na rozdil textovych editoru ap). Tak proc tady jeste neni CPU treba s 64 jednoduchymi a rychlymi ALU jednotkami? Je to vse jen problem stavajicicho SW a kompilatoru?
Odpovědět0 0
blecha2
|
17.8.20048:21
Ne na vsechno lze aplikovat pararelismus nebo za cenu zhorseni presnosti vysledku, bohuzel muj pripad.
K tomu Itaniu vyse, takze plati ma moznost 2 :) kod se sype primo do jednotek a decoder IA32 je jen berlicka pro nenativni kod.
Odpovědět0 0
blecha2
|
16.8.200412:01
Pokud je naitvnim kodem pro Itanium instrukcni sada IA32, ktera se dale dekoduje na RISC mikroinstrukce (neni to blbost?), pak jak muze mit kompilator softwaru vliv na pararelismus v RISC jadre? Napdaji me dve veci, 1. bud je sled nativnich Instrukci IA32 tak kompilatorem upraven, ze tok mikroinstrukci z dekoderu rovnou vyhovuje onomu pararelismu na nizsi urovni nebo 2. je kompilatorem vytvoren RISC kod, v podstate rovnou nativni mikroinstrukcni RISC kod a ten se rovnou mimo dekoder sype do vypocetnich jednotek a pak kompilator primo takto ovlinuje vytvorenym kodem vyuziti pararelismu v Itaniu. To by pak Ale bylo Itanium ciste RISC procak ne? A nebo je moje moznost 2 blbost...
Odpovědět0 0
Satrapa
|
16.8.200414:50
Odpověď je prostá - instrukční sada IA32 není nativním kódem Itania. Itanium vykonává instrukce IA64, které jsou zcela odlišné. Víc je na webu Intelu.
Odpovědět0 0
blecha2
|
16.8.200411:46
No zbytky z minulosti se jeste projevuji, takze i za pomoci informaci z netu zatim tvym informacim rozumim, navrhuji, az se dikuse trochu rozroste tyto nektere otazky a odpovedi dat pred zaver serie :). Ale mam problemek s tvym termine, scheduler rozhazuje ony mikroinstrukce do jednotek kde je urceno jejich zpracovani? Teda u Itania schedle jednotky nejsou, u P4 jsou mezi trace cache (cache s mikroinstrukcemi) a vlastnimi vypocetnimi jenotkami, u AMD je schedulinge mezi dekoderem a vypocetnimi jednotkami?
S tema nakresam deju v pipelajnech versus schema procesoru si teda musim dat pozor Intel i AMD je zacinaj teda kazdej jinak, trumberove..., no i kdyz to asi taky vliv tech vnitrnich rozdilu. A nuzu rict, ze tohle dost lidi, i me, mate, ted uz teda ne, ale stejne by to chtelo nekde popsat.
Co je druha faze dekodovani? Je to jeste soucast dekodovani instrukci na mikroinstrukce, nebo uz je to neco kolem scheduleru (jakysi rozhodnuti kam se so nahazi), pripadne jeste neco tesne pred vlastni vypocetni operaci?
Odpovědět0 0
Ano, scheduler třídí OPs těsně před výpočetními jednotkami. Druhá fáze dekódování je opět dekódování - zjevně se to nestihlo v jednom cyklu, tak na to musí být dva. I když záleží to na tom, co si pod to výrobce "přimaluje", může v tom být víc věcí.
Odpovědět0 0
blecha2
|
16.8.200411:11
Proc Intel zduraznuje ze ma napr. jeho P4 12 kB cahce na mikroops, to jsou dle me ty mikroinstrukce za dekoderem, a AMD o nicem takovem nemluvi? Takhle me to pripada jako kdyby AMD melo L1 cache na instrukce pred dekoderem a za nim nic a rovnou sup s tim do vypocetnich jednotek, zatimco P4 si dopredu nasysli mikroinstrukce v L1 cachy za dekoderem? Nekamenujte me, byl jsem linej se podivat na netu na schema obou procaku (p4 versus AMD32, AMD64). Jen mi to nejak nestimuje. Na Data ma L1 jak AMD tak IP4 oddelenou od L1 na iinstrukce , to vim. Jen mi to pripada, ze P4 ma L1 na mikroinstrukce a AMD na x86 instrukvce, stejne jako Itanium, viz obrazek v clanku. Teda predpokladam, ze to dekodovani v pipelajne (viz obrazky) je jeste na nizsi urovni, ale to mi nejak nesedi, mam z toho gulas asi ty nakresy jsou na schematicky rozdilne urovni a ja jsem z toho ted jelen. Pomoooc :-(.
Odpovědět0 0
Je to tak. P4 tahá x86 instrukce z L2, dekóduje (1 dekodér) je a ukládá (jako OPs) do Trace cache, odkud se pak vyvolávají rychlostí 3 OPs / cyklus do schedulerů. P4 nemá instrukční L1. Athlon tahá x86 instrukce z L1 instrukční cache, dekóduje je (3 dekodéry) a posílá do schedulerů. V Intelu počítali s tím, že OPs se budou v Trace cache recyklovat - pokud bude potřeba stejná instrukce, prostě se rovnou vezme v dekódované podobě z Trace cache, nebude se dekódovat znovu. V tomto je zajímavá jedna věc - P4 má 20 stupňů pipeline, ale to je od Trace cache na konec, dekódování do této hodnoty započtené není. Naopak Athlon má 10 stupňů od začátku na konec.
Výhody/nevýhody jsou zřejmé, Athlon dokáže vyvolat více OPs za cyklus (taky na stejné frekvenci podstatně rychlejší), naopak P4 dekóduje neustále, protože situace ve schedulerech není brzdou - v Athlonu často jeden nebo dva dekodéry stojí, protože situace v pipeline (paralelismus) neumožňují poslat další OPs.
Odpovědět0 0
Satrapa
|
16.8.200411:09
Předvídání skoků (zde spíše "předvídání výsledků") opravdu není žádná "černá magie", algoritmus není nijak složitý a je přesně popsán v dokumentech, které jsou jak u Intelu, tak u AMD ke stažení.
Odpovědět0 0
blecha2
|
16.8.200411:00
Ja si nemuzu pomoct, ale tohle me zajima - zbytky konicka z hluboke minulosti - stourani ve strijaku :). Rozhodne je to mnohem zajimavejsi nez diskuse typu ATI ruleeez, Intel ruulleeeez apod. blbiny...
Pod dnesnim terminem upgrade microcodu procesoru prostrednictvim biosu se rozumi v podstate uprava algoritmu dekoderu instrukci na RISC mikroinstrukce v procesoru?
Odpovědět0 0
Myslím, že ano. Sice to nemůžu říct s jistotou - dokumentace v podstatě jen říká, že se má nahrát 2048byte dlouhý mikrokód dodaný Intelem, ale co přesně v něm je, to už se nezmiňuje - ale jiný způsob opravování chyb mě nenapadá.
Odpovědět0 0
Mno já taky o microcode update moc nevím, ale asi to tak úplně nebude, protože potom by neměl být problém do starších CPU přidat např. SSE3 (tzn. když to přeženu, tak by se dalo např. PII naučit SSE/SSE2/SSE3/3DNow apod..) jen microcode updatem. A nebo to jde a vše je opět řízeno marketingem ?
P.S. taky jsem konečně rád, že se člověk dozví něco z technologie. Kdo se má pořád koukat na ty diskuze rulez ten rulez onen ;-). Například jsem věděl, že pipelining pomáhá kmitočtu (na vejšce to do nás hustili vrchem spodem včetně architektur po PI), ale už ne, že je to kvůlivá fyzikálním limitům rychlosti přenosu.
Odpovědět0 0
noname
|
17.8.200416:19
Ano je to tak. Vyrobce si tak nechava zadni vratka na optimalizace, na ktere pri vyvoji nezbyl cas.
Odpovědět0 0
noname
|
17.8.200416:19
Ano je to tak. Vyrobce si tak nechava zadni vratka na optimalizace, na ktere pri vyvoji nezbyl cas.
Odpovědět0 0
blecha2
|
16.8.200410:55
Jestli to tady i jinde na netu dobre chapu, tak x86 procaky rozkladaji instrukce x86 na mikroinstrukce az od dob pentia pro? Ja jsem naposled programoval v assembleru na ZX spectru, tak me to zajima. Driv mnou vytvorene instrukce pres assembler procak primo nativne vykonaval. Tkahle to tedy fungovalo az do Pentia MMX, pak uz bylo predelano na RISC jadro. Takze od pentia pro je mozne pres update biosu menit microcod procesoru a tim i jeho chovani v urcitych aplikacich, takze ho jaksi do urcite miry optimalizovat (ovlivneno samozrejme vnitrni architekturou) na urcity sled instrukci a tak i aplikaci? Itanium emuluje x86 taky pres rozklad na mikroinstrukce nebo ma nad procesorem nejakej vyssi dekoder? Samozrejme, protoze jeho architektura pocitala od zacatku s jinou instrukcni sadou, tak to neni moc efektivni, zatimco u x86 vyrobci procaku tak nejak maji pred sebou x86 instrukcni sadu a optimalizuji dekoder na mikroisntruce + RISC jadro pod nim tak nejak spolu (obcas si nejake nove instrukce primysli, ktere sedi prave tomu jejich RISC jadru po dekoderem lepe - SSE2 apod.). Jsou moje zavery spravne nebo uz kecam z hladu?
Odpovědět0 0
Ano, Pentium Pro je první čip Intelu s podporou Microcode update. Od AMD byl první RISC procesor K6.
Co se týče Itania, tak pokud jsem dobře poslouchal (moc jsem se tím nezabýval), nemá scheduling jednotky. Paralelismus určuje kompilátor, na jehož kvalitě tak velmi silně závisí výkon (Itanium 2 má 6 ALU a 2 FPU). A pokud jde o x86, existují dva způsoby - hardwarový překladač (dost neefektivní, rychlost na úrovni prvních Pentií) a softwarový, kde je rychlost již docela slušná (poloviční proti Xeonu na stejné frekvenci?). Softwarový překladač má výhodu také v tom, že jeho updatem je možné přidat další instrukční sady, samotné Itanium 2 totiž umí z x86 jenom SSE, ne už SSE2 nebo SSE3.
Odpovědět0 0
blecha2
|
16.8.200411:23
Jo jo, ted je mi to jasny, taky jsem vyzkoumal informace, kde se psalo o prekladu na urovni hardware, a pak na urovni software. ten software je ted na 50% mozne efektivity a Intel to chce dohnat na 70% efektivity a to je pry realne maximum toho softwaroveho prekladace u Itania. Ale mam dojem, ze texh 100% je, ze 1,8 GHz Itanium 2 by pak melo pri 100%ni efektivite vykon v x86 na urovni 1,8 GHz Xeonu (proste jako na obdobne frekvenci). A nebo ze by to melo vykon uz pri te 70%ni efektivnosti? Ted uz nevim..., ono taky zalezi jestli pro jednu silne vytezujici aplikaci, nebo pro nekolik aplikaci najednou. Ale sila Itania je v mohutnem pararelismu bez podpory na miru zkompilovaneho softu je mu to vicemene naprd, bych rekl. Na prisne deterministicke aplikace, si myslim, je lepsi, nez Itanium P4 nebo spis AMD, zalezi na typu vypoctu. To bude i problem s viceprocesorovymi aplikacemi, bohuzel ted pouzivam prisne deterministickou aplikaci simulaci nejaky biologie a i sami vyvojari toho pekne mastnyho softwaru mi z ameriky napsali, ze bohuzel uz z principu je vicevlaknovy vypocet komplikovany az spis nemozny :-(.
Odpovědět0 0
Mirek Petricek
|
25.8.200410:16
Pokud označujete jako RISC procesor, architekturu, kde procesor prekláda x86 instrukce na své vlastní mikroinstrukce a ty pak provádí, tak prvním procesorem od AMD byl už K5. K6 pouze tuto koncepci rozšířil o některé nápady, které získal akvizicí NexGenu.
Odpovědět0 0
noname
|
17.8.200416:16
Vsechny x86 i Z80 alespon nektere instrukce rozkladaji na mikroinstrukce.
Rozdil je v tom, ze az od Pentia Pro se poradi vykonavani mikroinstrukci muze menit podle potreby.
Odpovědět0 0
blecha2
|
16.8.200410:05
Teda Eagle, jeste jsem to nedocet, ale rychle si oprav to o tech elektronech a 300 000 km/s, toto s tim vakuem lze rici jen o elektrickem, gravitacnim, magnetickem aj. poli. O elektronech to mozna nekdy v budoucnu muze platit az bude vytvorena kvantova teorie gravitace (tzv. teorie vseho), ale i tak by to byl spis nejakej figl. 1. elektrony se pohybuji v materialu relativne dost pomalu (zvhledem k pouzivanemu napeti, snad jen mm/s -milimetry za sekundu - clovek znaly si muze zrychleni elektronu pri 1,5 V spocitat pri vzadelostech v procesoru, ale to si ted nejsem jistej), pouze el. pole se siri nejakejch o neco malo nez 300 000 km/s ve vakuu, hnidopich by rekl 299 792.458 km/s ;-). V soucasnosti nelze elektrony na 300 000 km/s urychlit ani za boha, no dobre prilis se drzim textu.... Ale i tak urychleni elektronu na , rekneme,298000 km/s ;-) pouze elektrickym polem by si vyzadalo slusne velkej rozdil elektrickeho potencialu, nebo dost slouhou drahu (vynechavam cyklotrony). Honem dostudovat a opravit :-).
Odpovědět0 0
blecha2
|
16.8.200410:07
Tak jsem to chtel rozvinout a SATRAPA me predhonil :).
Odpovědět0 0
Opraveno stylem pro "nehnidopichy" :-).
Odpovědět0 0
gekko
|
16.8.200411:21
Pokud už v tom šťouráš, tak tě ještě popravím. Elektron, ani žádnou jinou částici s nenulovou klidovou hmotností na oněch 299792.458 km/s urychlit nelze už z principu. Prostě proto, že bys k tomu potřeboval nekonečné množství energie.
Rychlostí cca 300000 km/s se šíří elektrické a magnetické pole. Gravitační síly působí okamžitě.
Orel: Moc pěkný článek, už se těším na pokračování :-)
Odpovědět0 0
blecha2
|
16.8.200411:28
Ja vim, jsem to zamotane napsal, ze to tak vypada, proto tam je ta zminka o kvantove teorii gravitace a spis o tom figlu. Tam melo byt, ze urychleni na temer...., proto dal pisu o urychleni na 298000 km/s. Vsak jsem si tech blbin uzil, u jedny zkousky na vejsce jsem si totiz kdysi davno vytahnul Einsteina, tak jsem musel odvozovat ony slavne rovnice s tim clenem, kde je odmocnina z podilu v na druhou lomeno c na druhou, ale zmaknul jsem to :oD.
Odpovědět0 0
Paloooooooooo
|
16.8.200420:35
gravitacna sila sa siri iba rychlostou svetla
Odpovědět0 0
Petrik-MFF
|
24.8.200410:51
Gravitacni pole se opravdu nesiri okamzite, nevim, kde jsi na to prisel, ale odporovalo by to obecne teorii relativity. PRave duvod, ze se siri pouze rychlosti svetla zpusobuje, ze mohou vznikat graitacni vlny, ktere se nyni snazi vsude na svete detekovat :-)))
Jinak vybornej clanek, jeden z nejlepsich, ktery jsem kdy cetl.
Odpovědět0 0
Satrapa
|
16.8.200410:00
Jen malý detail - elektrony se nepohybují rychlostí světla, tou rychlostí se pohybuje elektromagnetické pole. Elektrony samy se při běžných proudech pohybují rychlostmi o mnoho nižšími, řádově jen několik milimetrů za sekundu.
Odpovědět0 0
hondasek
|
19.5.20058:22
Elektrony se pohybuji v řádech 10 na 5tou m/s pri pokojové teplotě
Odpovědět0 0
Petrik svetrik
|
19.5.200510:43
Ani nahodou, doporucuji prostudovat skripta pro MFF, mam z toho za jedna :))
Odpovědět0 0
Docela by mě to zajímlo, sou někdy ty skripta k nahlídnutí???
Odpovědět0 0
Asi by se melo uvest, kde a za jakych okolnosti. Ve vodici pri pruchodu proudu zdaleka ne. Volne elektrony v plazmatu uz jsou podstatne rychlejsi. A skutecne vysokych rychlosti dosahuji ve vakuu pod vlivem vnejsiho el. pole, napriklad v elektronkach.
Odpovědět0 0
Jakub Hegenbart
|
13.3.200613:00
To si pleteš s driftovou rychlostí...
Odpovědět0 0
Golem
|
16.8.20049:34
už se těším na zítra. :-)
Odpovědět0 0